не совсем понял для чего в этом месте используется регулярка.
у вас ведь есть схема для всех полей в :field-type так? можно например используя эту информацию парсить строки с помощью функций parseInt и parseDouble. Только надо будет в try catch завернуть на случай ошибок

Если честно не нашел функций parseInt и parseDouble.
Сначала была именно такая задумка. Но потом решил пойти таким путем и мне кажется он проще.
а :field-type это уже артефакт скорее

я имел ввиду эти функции
(Integer/parseInt "1")
(Double/parseDouble "1.3")

Я уже нашел.
Но никак не привыкну, что в Java есть все и нужно искать там. В ней я вообще не знаком

а что конкретно проверяет регулярка?

вот это не кажется валидным числом

Проверяет число или нет. Косякнул.
Правильная регулярна #"\d+\.?\d*"
Исправил.

вижу что find-row используется в связке с first, но при этом filterv зарелизит всю коллекцию сразу,
если оставить просто filter то результатом будет lazy sequence и в связке с first обход элементов остановится на первом найденом элементе

Не только.
find-row либо вернёт одну запись, если ищет по id, либо вернёт массив, который тут же будет релизится, что бы посчитать данные для отчета.
Имеет ли смысл тогда исправлять? first тут нужен что бы избавиться от вектора, в котором есть одна запись

кажется тут подошла бы функция juxt https://clojuredocs.org/clojure.core/juxt
если сделать из args набор функций то можно обойтись одним map без for
например так (map (apply juxt args) rows) и это уменьшит количество выполняемых действий: один проход по args + map по количеству rows вместо args * rows операций

Спасибо за наводку на интересную функцию.
Но тут, вектор из ключей не два поля одной хэш-мапы, а таблица и поле из которых нужно достать значение по id.
Задача функции get-val определить из какой таблицы брать какое поле. И вернуть нужное значение

я имел ввиду что-то вроде такого

(let [arg-functions (map #(partial get-val db %) args)
        arg-rows (map (apply juxt arg-functions) rows)])

arg-functions - тут будет набор функций и все они вызовутся на каждой строке
тоже самое что и вашем коде но без использования for
так не обязательно делать просто упомянул что есть еще и такая возможность

Все, понял!
Спасибо за наводку. Использовал в тексте

тут семантически больше подошел бы loop. reduce он все же про работу с коллекциями

Вот был сначала loop :)
Но за него в последнее время ругают

прям ругают? ))
в использовании loop/recur нет ничего плохого
мне кажется в чате как раз разговор был о том что есть ситуации когда loop действительно подходит лучше чем всё остальное (например когда вам явно нужен бесконечный цикл или когда количество итераций не определенно заранее), но есть и другие ситуации когда нужно пробежаться по коллекции или агрегировать коллекцию по какой то функции, тут есть специализированные методы (map, reduce)
Конкретно в этом случае loop выглядит идеально (мы не знаем сколько команд введёт пользователь)

Ну засмущал Алексей :)
Первоначально и был loop.
Потом открыл для себя repeatedly
В принципе я изначально так строил приложение, что все функции меню возвращают db, которая прокидывается дальше. Поэтому это решение прямо идеально легло.
Но я помню - reduce он для данных

👍 отличный подход, использовать хэш папу как функцию

Это меня и завораживает в Clojure: почти все - функция

напрашивается ->

(-> name
      (calc-report db rep)
      (format fmt name)
      println)

читать сверху вниз зачастую легче чем справа на лево

Согласен. Но пока не всегда подключаются в мозгу такие решения.

👍